home *** CD-ROM | disk | FTP | other *** search
/ Skunkware 5 / Skunkware 5.iso / src / Tools / ecu-3.35 / README.KEYBRD < prev    next >
Text File  |  1995-07-13  |  7KB  |  168 lines

  1. ECU 3.20 presents itself to the world by default as a much
  2. better clone of an SCO multiscreen terminal than ever before.
  3.  
  4. This includes
  5.    video display control and
  6.    key codes emitted by pressed function keys
  7.  
  8. In addition, many MS-DOS video control sequences are supported.
  9.  
  10. These features are described in tedious detail in the manual.  What is
  11. missing from the manual -- and what this README attempts to
  12. describe -- is how ECU keyboard management really looks from the
  13. macro perspective.
  14.  
  15. Keyboard management is divided into two parts:
  16.  
  17.   o  Function key recognition
  18.   o  Function key action
  19.  
  20. Function key recognition means detecting function key presses
  21. in the ecu keyboard input stream.  This is controlled by the
  22. ~/.ecu/funckeymap file.
  23.  
  24. Function key action means what ecu does with a function key once
  25. it gets it.  This is controlled by the ~/.ecu/keys file.
  26.  
  27. Function Key Recognition 
  28. ------------------------
  29.  
  30. You have to use funckeymap entries to get ecu to recognize the
  31. function keys.  Pre-3.20 users take note: funckeymaps serves the
  32. purpose previously handled by ~/.ecu/nonansikeys.  This is a rare
  33. backward compatibility problem (the 2nd in ECU history).
  34. Starting with 3.20, SCO multiscreens require an entry, whereas
  35. earlier versions had multiscreen support built in.  The TERM name
  36. for SCO multiscreens is "ansi", hence the name "nonansikeys".  I
  37. think you'll agree the new name is more appropriate.
  38.  
  39. If ~/.ecu/funckeymap does not exist, ECU searches for a file
  40. by  the same name in the library directory, usually /usr/local/lib/ecu).
  41.  
  42. At startup,
  43. ECU selects an entry in ~/.ecu/funckeymap whose label matches
  44. the terminal type of the executing screen (the TERM environment
  45. variable).  If ecu is started
  46. non-conversationally (/dev/null for stdin), this is not done.
  47. The environment variable ECUFUNCKEY, if found, overrides the
  48. TERM variable for funckeymap keyboard management only.  TERM is always
  49. used for identifying the display.
  50.  
  51. See the manual sections titled "Supported Terminals" thru "Line Editing".
  52. There are some additional notes in the distribution file
  53. models/funckeymap.  Please forgive any conflicts.  I can only
  54. type so fast and the code gets priority.
  55.  
  56. An example entry for an SCO multiscreen console:
  57.  
  58. #+-------------------------------------------------------------------
  59. #   SCO  multiscreen  ($TERM=ansi)
  60. #--------------------------------------------------------------------
  61. ansi
  62. ansi43
  63. sco
  64.     F1:F1:          esc [ M 
  65.     F2:F2:          esc [ N 
  66.     F3:F3:          esc [ O 
  67.     F4:F4:          esc [ P 
  68.     F5:F5:          esc [ Q 
  69.     F6:F6:          esc [ R 
  70.     F7:F7:          esc [ S 
  71.     F8:F8:          esc [ T 
  72.     F9:F9:          esc [ U 
  73.     F10:F10:        esc [ V 
  74.     F11:F11:        esc [ W 
  75.     F12:F12:        esc [ X 
  76.     Home:Home:      esc [ H 
  77.     End:End:        esc [ F 
  78.     PgUp:PgUp:      esc [ I 
  79.     PgDn:PgDn:      esc [ G 
  80.     CUU:CUU:        esc [ A 
  81.     CUL:CUL:        esc [ D 
  82.     CU5:CU5:        esc [ E 
  83.     CUR:CUR:        esc [ C 
  84.     CUD:CUD:        esc [ B 
  85.     Ins:Ins:        esc [ L
  86.     BkTab:BackTab:  esc [ Z
  87.  
  88. ECU tries to support any "reasonable" video terminal as an ECU
  89. console.  Video differences are handled by curses and
  90. termcap/terminfo.  The keyboard is normalized with funckeymap.
  91. Hopefully, someone has already constructed a funckeymap entry for
  92. your keyboard.  If not, you must construct one.
  93.  
  94. For this, make several experiments with kbdtest3.
  95. Start a terminal session in the ecu distribution directory
  96. and run kbdtest3 (assuming it has been made).
  97. Kbdtest3 will prompt you to press each function key in return.
  98. The program is generally self-explanatory, but some notes are
  99. worthy of note:
  100.  
  101.   o If it asks you for a key not on your keyboard, pick some
  102.     reasonable alternate
  103.  
  104.   o If you simply cannot find an alternate, you will have to type
  105.     a slash ('/') to signify no key choice exists.
  106.  
  107.   o If you are on an xterm, you may get spurious or no response
  108.     for the "unusual" keys like Home and End.  Just type a
  109.     slash for the time being and go on.  When you are finished,
  110.     re-read the manual section titled "Function Key Mapping
  111.     (Recognition)".  There are also some notes in models/funckeymap.
  112.     There are guidelines in there for using xmodmap to achieve
  113.     reasonable X mapping for spurious or dead keys.
  114.     A notorious example is the xterm shift-Tab that generates
  115.     the single character sequence 0x09 just like the tab key does.
  116.  
  117.         XTerm*VT100*Translations: #override\
  118.              Shift <Key>Tab:  string(0x1b) string("[Z") \n \
  119.  
  120.     in ~/.Xdefaults takes care of this.
  121.  
  122. Repeat the kbdtest3 and hackery exercises until you have an
  123. acceptable entry.  Acceptable means a working key for each of
  124. ecu's 23 function keys where each key produces a
  125. unique key sequence.
  126.  
  127. Kbdtest3 writes funckeymap entries to ./kbdtest3.out.  When you
  128. edit the file, you will see the results of each kbdtest3
  129. run appended one after the other.  Presumabaly you quit using kbdtest3
  130. when you were satisfied, so skip to the bottom of the file and examine the
  131. last entry.  If it looks good, cut that section out and put
  132. it in ~/.ecu/funckeys.  Also, -*PLEASE*- send it to wht@n4hgf.atl.ga.us
  133. so I can archive it.  Include the environment details
  134. such as "Wyse 232XKQ Rom revision 2.3" or "Pluton 9001 console
  135. under RiskOs 1.4".
  136.  
  137. Now ecu can recognize your function keys and map them to internal
  138. values.  Command screens needing up and down arrows, insert and
  139. so forth will work.  
  140.  
  141. Function Key Actions
  142. --------------------
  143.  
  144. Function key actions are determined by ecu program code when
  145. you are executing ecu interactive commands.  When you are
  146. in the interactive mode, keyboard actions are governed by
  147. startup definitions or ~/.keys actions.  These are described
  148. in the manual section titled "Function Key Actions", but a
  149. few quick notes here might serve well:
  150.  
  151.    o  startup default actions
  152.       All of the 23 function keys save 2 are preset to generate
  153.       the same sequence they would on an SCO.  See the manual
  154.       subsection "Standard Function Keys" for a list
  155.       The 'Home' and 'Cursor 5' keys have reserved meanings
  156.       and may not be overriden.
  157.  
  158.    o  ~/.keys and the interactive command fkey
  159.       You can override the defaults by loading a custom keyset
  160.       you have placed in ~/.fkeys.  The interactive command
  161.       fkey may be explicitly used to load a keyset.
  162.       If you use a logical dialing directory name to connect
  163.       to a remote and ~/.keys has an entry whose name (sometimes
  164.       called the label) matches the directory entry name, ECU
  165.       will load the ~/.keys entry automatically.
  166.       See "Standard Function Keys" for details.
  167.  
  168.